src/block/horizontal-scroller/frontend-horizontal-scroller.js (2)

9-9: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

dragTimeout is shared across all scroller elements

dragTimeout is declared once in init() scope and shared by every element's mouseDownHandler. On a page with multiple horizontal scrollers, scroller B's mousedown will clearTimeout(dragTimeout) mid-flight for scroller A, leaving scroller A permanently stuck with the stk--snapping-deactivated class.

🐛 Proposed fix — scope `dragTimeout` per element

         els.forEach( el => {
+            let dragTimeout = null
             if ( el._StackableHasInitHorizontalScroller ) {

-        let dragTimeout = null
         let initialScrollLeft = 0

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/block/horizontal-scroller/frontend-horizontal-scroller.js` at line 9, The
shared dragTimeout declared in init() causes cross-element interference; make
the timeout instance-scoped per scroller element by removing the single outer
let dragTimeout and instead attach a per-element timeout (e.g., el._dragTimeout
or a local let inside the per-element setup) and update all references in
mouseDownHandler, mouseMoveHandler and mouseUpHandler to use that per-element
property; ensure clearTimeout and setting to null happen on the same element
(and on cleanup) so one scroller’s mousedown won’t cancel another’s snapping
state (stk--snapping-deactivated).

---

53-79: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Stale click-blockers persist when the browser loses focus mid-drag (alt-tab / tab switch)

The fix correctly moves link re-enablement from inside the 500 ms timeout into mouseUpHandler. However, mouseUpHandler only runs when mouseup fires on document.body. Changing desktops or tabs while the mouse is held down results in no mouseup event on document in either Firefox or Chrome on Windows. This means:

1. User starts dragging → mouseMoveHandler attaches onClickHandler to every child.
2. User alt-tabs while holding the button → mouseup never fires → mouseUpHandler never runs → click listeners remain on children.
3. User returns to the tab and clicks a link → first click is consumed (re-creates the original bug).

This matches the issue's stated symptom: "The behavior recurs when a browser tab loses and regains focus."

The well-known mitigation is to treat window.blur as a drag-end signal and run the same cleanup:

🛡️ Proposed fix — add a `window` blur handler

         const mouseUpHandler = function() {
             document.body.removeEventListener( 'mousemove', mouseMoveHandler )
             document.body.removeEventListener( 'mouseup', mouseUpHandler )
+            window.removeEventListener( 'blur', mouseUpHandler )

             el.style.cursor = ''
             // ... rest unchanged
         }

         const mouseDownHandler = function( e ) {
             // ...
             document.body.addEventListener( 'mousemove', mouseMoveHandler )
             document.body.addEventListener( 'mouseup', mouseUpHandler )
+            window.addEventListener( 'blur', mouseUpHandler )
         }

One effective mitigation is to add an additional blur event handler on window; the blur event fires when the window loses focus, and ending any drags in progress when this event fires produces a safe approximation of the true mouse state.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/block/horizontal-scroller/frontend-horizontal-scroller.js` around lines
53 - 79, The drag cleanup in mouseUpHandler never runs if the tab/window loses
focus mid-drag, leaving click-blockers attached; add a window 'blur' listener
when starting a drag (where mouseMoveHandler is attached) that invokes the same
cleanup as mouseUpHandler (or calls mouseUpHandler) so children have
onClickHandler removed, dragTimeout cleared/handled, and class toggles restored;
also ensure the blur listener is removed inside mouseUpHandler after performing
the cleanup to avoid leaks.